Subject: COS Tables for Subnets with Priority Service

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Fri, 7 Jul 95 15:09:47 EDT

Hi Dave,

>You've raised some good points. I am a little confused about use of
>cost as you've described. Surely, according to the way you have
>described it, *all* private lines have a cost. Cable costs money,
>hardware support, bridges, etc, cost money. If a line is used heavily
>and becomes congested, a new one may need to be installed, or the
>equipment upgraded, etc.
>
>Therefore, it would seem that all TGs have some cost associated, which
>is clearly not the intention of the architecture. As far as I am
>aware, cost is intended to reflect external costs caused by use of the
>TGs (by time or traffic volume).

The intention of the architecture is to accurately reflect the
characteristics of available links so that route selection can do
its job correctly.  The default cost/byte and cost/time characteristics
for the various link types (see table 7-38 on page 7-66 of the APPN
Architecture Reference) were chosen to reflect the marginal cost
associated with their use.  The idea was that LANs and leased wide-area
facilities had primarily fixed costs, but that switched wide-area links
had the marginal cost of tariffs paid to the carrier.

I would argue that there is a marginal cost associated with using
a priority service in a private network.  Admittedly, it is not
dollars being paid to an outside agency, but it is real nonetheless.
Every time a high-priority packet jumps ahead of lower-priority traffic,
the performance of the lower-priority traffic suffers.  In order for
route selection to consider this cost, it must either be reflected in
an existing TG characteristic like cost/byte or in a new characteristic
and associated COS table column.

The current values for the default TG cost characteristics are very
coarse.  LANs and leased facilities are free (i.e., have 0 values for
both cost characteristics) and leased facilities have a 128 value for
both.  Essentially, as far as the default characteristics are concerned,
cost is a binary variable.  As a result, reflecting the cost of a
private priority service in the cost/byte characteristic can be
accomplished without a lot of fine tuning; for example, such a cost
could be assigned any value between 0 and 128.

>So again, it seems, we need to "fiddle" with the definitions to
>achieve Jim's aim. More importantly, this fiddling is totally out of
>our hands. The customers may not have the expertise to understand the
>issues, and I think all of us would do some long hard thinking before
>we chose values for cost/propagation delay in this case, as we *know*
>we could affect network performance.

If we use proper care (or long hard thinking) to define TG
characteristics that represent real link capabilities and to design COS
tables that base route selection on these link capabilities, I see
no reason we can't maintain or improve network performance.  My fear is
that fiddling with the definitions and tables in a manner that doesn't
reflect real link capabilities will make it more difficult to handle
future services; for example, route selection will need to compare
links with priority service with ATM links with reserved bandwidth or
best-effort service.

Gary Dudley
IBM APPN Architecture Team

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 10 Jul 1995 14:57:00 -0400

>could be assigned any value between 0 and 128.

I think that Gary has some good points here.  If the underlying network is a
public one, then it will actually charge more for priority service than for
normal service.  If it did not everyone would send their traffic as high
priority, and the whole mechanism would be defeated.  Also in many private
networks, the network is a service which is provided to the end departments
by a separate service organization.  Indeed many corporations have farmed
this service out to a facilities management company.  In any network there
must be some penalty associated with the use of high priority connections to
ensure that they are reserved for the intended users.  That penalty may not
always be a simple financial one, but it does seem reasonable to code a
higher cost-per-byte and/or cost-per-connect-time for transmission groups
using high priority sub-network connections from those using low priority
connections.

The specific routing problem that my customers are looking for a solution for
arises out of the fact that the ranges of values for all rows of all COS
entries overlap.  So even if we agree that high-priority TGs should have a
higher cost-per-byte (for example) than low-priority TGs crossing the same
medium, we must change the COS tables to ensure separation of high-priority
COS traffic from low-priority COS traffic.

For example the current default COS entries with a TG which has
packet-switching type delay (X'91') (and ignoring all other attributes except
cost/byte) you would get the following weights for TGs:

  TG cost/byte       COS names                     weight
     1 - 128      #INTER, #INTERSC		    150
   129 - 196      #INTER, #INTERSC                  210
   197 - 255      #INTER, #INTERSC                  240

     1 - 128      #BATCH, #BATCHSC                   90
   129 - 196      #BATCH, #BATCHSC                  180
   197 - 255      #BATCH, #BATCHSC                  240

Because the ranges of cost/byte overlap between the high-priority and
low-priority COS entries, it is not possible to select values of cost/byte
which will cause certain TGs to be exclusively used by high-priority traffic
and others by low-priority traffic under normal circumstances.

One approach is to consider that if TRS has got down to a packet switching
connection as the best available route for a session, then cost per byte is
probably not an issue for interactive sessions, but is an issue for batch
sessions.  So default rows 5 and up of the #INTER, #INTERSC, #CONNECT,
CPSVCMG, and SNASVCMG COS entries should probably not impose a cost
constraint.  Since my customers actually WANT to use high-priority VCs for
this traffic, indeed they would want a cost/byte range of (say) 129-196 for
rows 5 through 7.  For the batch COS entries, on the other hand, cost is
always an issue, so the existing ranges can be retained.  Then if a TG for
a low-priority VC is given a cost/byte in the range 0-128 it will be used
exclusively for batch traffic under normal circumstances.  Conversely if a TG
for a high-priority VC is given a cost/byte in the range 129-196 it will be
used exclusively for interactive traffic under normal circumstances.